1.3 Architecture

Decoupling the link shortener from analytics allows for flexible configuration fitting many use cases!

As outlined in the previous Design Goals section, the request path for any request on the "shortener" url (ex.co/foo) looks as follows:

First request (most likely you):
user <--> CDN <--> blink
           ^
           ㄴ-> access log

Following requests (the redirect is cached):
user <--> CDN --> access log

If you don't want to bother with a CDN:
user <--> blink --> access log

For analytics, you have two options. You can either go with the "serverless" route (and the blink server + postgres db should be lightweight enough to be effectively serverless, making the entire stack ops-free), or the OLAP route (more traditional), where you shove everything into an OLAP database and just query it that way (there are more UIs built for this):

Serverless route:
access log --> lambda ETL --> store in S3 in columnar format (e.g. parquet) --> query w/ Athena

OLAP route:
access log --> ETL --> add row to OLAP --> query w/ some prebuilt solution

Intimidated? Don't be. You can use the CDN's built-in analytics (e.g. CloudFlare, Fastly) for an out-of-the-box solution!